Many computer applications run in non-interactive mode (not requiring input from the user) but must occasionally provide information to or elicit information from the user. Various methods exist to perform one-way communication to the user but they require elevating the user privilege or providing unsecured data routes back to the centralized process. This situation may arise when a user is required to activate software, for example after installing a new operating system. Product activation works by verifying that a software program's product key, which the user must use to install the software, has not been used on more computers than intended by the software's license.
After installation of the software product, a service is activated in the system that will notify the user that the product needs to be activated. The user can then use an activation wizard associated with the computer to provide the software product ID to the software vendor. This can be done through the internet or by phone. After the vendor checks its database to make sure that the software product ID is not being used to activate unlicensed software, the vendor will provide the user with a confirmation ID to activate the product. Typically, if the software product is not activated after a predetermined number of launches the software product will go to a reduced functionality mode (e.g. preventing the creation or editing of files). The activation of the product is done by a user with administrative privileges.
In computing, if a task is performed by a user having more privileges than necessary to do that task, there is an increased risk of inadvertent harm to computer resources. For example, if a file can only be deleted by a user with administrator privileges, then a user using an administrator account may inadvertently delete the file when performing another task that does require administrative privileges. If the user had been a user having lesser privileges, then the intended task could still have been performed but the inadvertent deletion would not have been allowed.
Thus, a recognized goal in computer security is the concept of least privilege, in which a user performing a task should run with the absolute minimum privileges (or identities, such as group memberships) necessary to do that task. However, there is no convenient way to add and remove a user's access rights and privileges. For example, in a typical operating system, when the user logs on, an access token is built for the user based on the user's credentials. The access token determines the access rights and privileges that the user will have for that session. As a result, the user will have those privileges for each task attempted during that session and for any future sessions. While ideally an administrator can set up multiple identities and log-on as a different user with different rights for each task, this may be considered burdensome.
In short, there is simply not a convenient way to change privilege levels or access rights, nor a way to further restrict privileges at a granularity finer than that created by the domain administrator. Other operating systems have similar problems that make running with least privileges an ideal that is rarely, if ever, practiced.
Providing a secure mechanism to notify and support users is a missing component in many systems. Ad hoc methods are available to launch applications or use insecure data pathways that can be intercepted by non-administrators and used in attacks against the system. The proposed methods here provide a simple, standardized way of solving this problem.